A data processing environment comprises a variety of hardware, software, and firmware networking components. A physical network, also called an underlay, is a network defined using such components.
Techniques are available presently to construct a logical network, also known as a software defined network (SDN) overlay (hereinafter interchangeably, “SDN” or “overlay”), from such networking components. Essentially, networking components are abstracted into corresponding logical or virtual representations, and the abstractions are used to define the SDN. In other words, an SDN is a logical network formed and operated using logical representations of underlying networking components.
Physical networks usually exist within the demarcated boundary of the data processing environment whose networking components are utilized in the physical network. Unlike a physical network, an SDN can be designed to span across one or more data processing environment. For example, while a physical network may be contained within a datacenter, an SDN may span across one or more datacenters.
As an example, a logical representation of a hypervisor can participate in an SDN, such that a function attributed to the logical representation of the hypervisor in the SDN is actually performed by the underlying hypervisor component in the underlay. Similarly, a logical representation of a networking gateway can participate in an SDN, such that a function attributed to the logical representation of the networking gateway in the SDN is actually performed by the underlying networking gateway component in the underlay.
In an SDN, because the actual networking components that perform the networking functions are abstracted into logical entities representing the networking functionality offered by those components and not the actual implementations of those functionalities, something is needed to direct those networking functionalities into a functioning logical network. An SDN controller is a component that manages and operates the logical networking components within an SDN.
Henceforth in this disclosure, any reference to a component within the context of an SDN is a reference to a logical representation of the component, which participates in the SDN, unless expressly distinguished where the reference is made. For example, a reference to a hypervisor in communication with an SDN controller is a reference to a logical representation of the hypervisor that operates in the SDN managed by the SDN controller and not to the hypervisor component of a machine that actually performs the tasks commanded by the SDN controller.
A virtual machine (VM) comprises virtualized representations of real hardware, software, and firmware components available in a data processing system. The data processing system can have any number of VMs configured thereon, and can utilize any number of virtualized components therein. The data processing system is also referred to as a computing node, a compute node, a node, or a host.
For example, the host may include a processor component. One virtual representation of the processor can be assigned to one VM, and another virtual representation of the same processor can be assigned to another VM, both VMs executing on the host. Furthermore, the second VM may also have access to a virtual representation of a reserve processor in the host and certain other resources, either exclusively or in a shared manner with the first VM.
Certain data processing systems are configured to process several workloads simultaneously. For example, separate virtual data processing systems, such as separate VMs, configured on a single host data processing system often process separate workloads for different clients or applications.
In large scale data processing environments, such as in a data center, thousands of VMs can be operating on a host at any given time, and hundreds if not thousands of such hosts may be operational in the data center at the time. A virtualized data processing environment such as the described data center is often referred to as a “cloud” that provides computing resources and computing services to several clients on an as-needed basis.
Presently available methods for data communication in an SDN allow data to be exposed to snooping or tampering, or to otherwise remain accessible in plain text or original form, at least in some segments of the SDN. Such exposure of the data is undesirable.
For example, assume that a VM is operating in a host data processing system. A hypervisor component available to the host facilitates the data communication to and from the VM. For example, the VM sends a data packet to the hypervisor, the hypervisor sends the packet to a gateway component, and the gateway component encrypts the packet and sends the encrypted packet to a destination system.
In an SDN, the hypervisor and the gateway described above are logically represented and operate to provide the functionality described above in a similar manner. A hypervisor in a given SDN similarly hands off the data packet to a gateway in the SDN or another hypervisor in the SDN.
Presently, at least in a part of a given SDN, the data packet travels essentially a plain text form. For example, the SDN segment from the hypervisor to the gateway may be a part of a local area network (LAN), e.g., a cloud network in a data center that participates in a given cloud architecture. At least in this segment, the data packet sent by the hypervisor remains without encryption. For example, in this segment, a cloud component can snoop the data packet or perform a deep inspection of the data of the packet.
Similarly, one hypervisor in one host can receive a packet from one VM, handoff the packet to another hypervisor in another host, the other hypervisor delivering the packet to another VM in the other host. In this example as well, the segment between the two hypervisors in the SDN may allow the data of the packet to be maliciously or otherwise undesirably read in transit.
Presently, SDNs do not include a provision to perform end-to-end encryption of data. End-to-end encryption comprises encrypting the data of a data packet at the first component in an SDN path of the data packet, and decrypting the data at the last component in the SDN path, where the first and the last component are both managed by the same SDN controller. An SDN path is also known as an “SDN flow,” or simply “flow.”
For example, if a data packet originates at a VM in a host on a LAN and the destination of the packet is another VM in another host in the LAN, the first component of the SDN that handles the packet in the flow is the hypervisor at the originating host, and the last component that handles the packet in the flow is the hypervisor at the destination host. Communications between the VM and the hypervisor at each host are internal or local to the host and not a part of the SDN.
Similarly, if a data packet originates at a VM in a host on a LAN and the destination of the packet is a machine or component outside the LAN, e.g., on a wide area network (WAN), the first component of the SDN that handles the packet in the flow is the hypervisor at the originating host, and the last component that handles the packet in the flow is the gateway that transfers the packet from the LAN to the WAN. Communications between the VM and the hypervisor at a host are internal or local to the host and not a part of the SDN. The communication segments after the gateway are also a part of the SDN in that such segments are not under the control of the SDN controller that manages the hypervisor and the gateway.
Further, where a need exists to encrypt data at a hypervisor, custom applications or tools (collectively, “appliances”) have to be configured to operate with the hypervisor. Such an appliance also requires a corresponding counterpart appliance to be configured at the other hypervisor to form a pre-determined flow between the two hypervisors. Such custom configuration has to be pre-planned for each flow, and such appliances have to be installed with each participating hypervisor according to the pre-planned flows. Furthermore, the entire custom setup has to be maintained and kept in synchronization so that each appliance at each end of a given flow uses the exact same encrypting algorithm to successfully encrypt and decrypt the packets over the flow.
Thus, the presently-available SDN configuration does not have any standardized form of end-to-end encryption method. Further, any custom mechanism to encrypt data in an SDN segment suffers from numerous drawbacks, some of which are described above.